The present invention relates in general to graphics drivers and in particular to a kernel-mode graphics driver (such as a D3D driver) optimized for use in a dual-core computer system.
A graphics driver is a software component of a computer system that provides an interface allowing application and/or operating system programs to access functionality of a graphics processor or other graphics hardware without knowing low-level details of the hardware. A graphics driver typically implements a library of functions that can be called by application programs (if the driver runs in user mode) or operating system programs (if the driver runs in kernel mode); in the latter case, the operating system provides an interface layer between the application and the graphics driver.
FIG. 1 illustrates the execution of a conventional graphics application under the Microsoft Windows® operating system, using a kernel-mode graphics driver such as the D3D component of the Direct X® multimedia driver specified by Microsoft Corporation. In FIG. 1, a graphics application 100 executes on a central processing unit (CPU) 102. The application executes in user mode, meaning the application can directly access only a subset of system functions. As is known in the art, restricting applications' access to system functions helps to prevents applications from initiating operations that lead to system crashes or other undesirable results.
A graphics processing unit (GPU) 104 operates as a slave to CPU 102 to perform various graphics-related tasks, such as image rendering and/or display. GPU 104 is programmable using an instruction set that may be unique to a particular graphics device or family of graphics devices.
To allow application developers to use GPU 104 without knowing the details of its instruction set, a graphics driver program 106 is generally provided together with GPU 104. Graphics driver 106, which executes on CPU 102, receives a predefined, hardware-independent set of driver calls and generates corresponding instructions to the hardware. Various standard graphics-driver interfaces have been defined, such as Microsoft's D3D interface; each such interface includes a library of functions that graphics driver 106 recognizes and responds to by generations appropriate hardware-level instructions to GPU 104. A D3D graphics driver executes in a “kernel mode,” which allows unrestricted access to system functionality.
Graphics application 100, because it executes in user mode, is not permitted to invoke kernel-mode graphics driver 106 directly. Instead, the operating system (OS) includes a run-time component 108 that provides an interface between user-mode graphics application 100 and kernel-mode graphics driver 106. Specifically, run-time component 108 implements an application program interface (API) that provides a library of graphics function calls that application 100 can use to invoke functions of graphics driver 106. Run-time component 108 translates the API calls into graphics driver calls recognized by driver 106. One such API is a part of Microsoft's D3D specification.
During a graphics operation using D3D, the sequence of calls numbered 1-5 in FIG. 1 typically occurs. First, graphics application 100 makes an API call (1) to OS run-time component 108. The API call identifies an operation, such as setting a drawing color or drawing a primitive, that the graphics hardware is to perform. The API call transfers control from graphics application 100 to OS run-time component 108, and graphics application 100 waits for a response from run-time component 108 before proceeding further. Run-time component 108 validates the call (e.g., making sure that the call is appropriate given the current state of the system), then makes a corresponding call (2) to graphics driver 106 and waits for a response. Graphics driver 106, in response to call (2), transmits one or more hardware-level instructions (3) to GPU 104 for execution. After transmitting these instructions, graphics driver 106 returns control (4) to OS run-time component 108, which in turn returns control (5) to graphics application 100, which can then proceed. In some cases, when run-time component 108 returns control to graphics application 100, the return message may include an error or status code, which application 100 can use to determine a subsequent action. This error or status code can originate from graphics driver 106 or OS run-time component 108. Thus, the various operations performed by application program 100, run-time component 108, and graphics driver 106 are generally part of a single thread of execution in CPU 102.
Recently, personal computer systems with two or more processing cores have reached the marketplace. Such systems, referred to herein as “dual-core” systems, may include two (or more) cores in a single integrated circuit device, or chip, that functions as the system CPU, or they may include two (or more) processor chips that co-operate as a single CPU. Dual-core systems allow two (or more) processing tasks to be performed simultaneously using separate resources; the resulting parallelism can increase system performance.
However, even in dual-core systems, processing tasks associated with the same thread of execution, such as the various tasks associated with FIG. 1, must be executed sequentially to preserve system coherence. Consequently, conventional graphics application programs, which are single-threaded, do not realize a performance benefit when executing on a dual-core system.